home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19950329-19950528 / 000316_news@columbia.edu_Fri May 5 05:48:47 1995.msg < prev    next >
Internet Message Format  |  2020-01-01  |  5KB
  1. Received: from apakabar.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA26851
  2.   (5.65c+CU/IDA-1.4.4/HLK for <kermit.misc@watsun.cc.columbia.edu>); Fri, 5 May 1995 18:35:29 -0400
  3. Received: by apakabar.cc.columbia.edu id AA15380
  4.   (5.65c+CU/IDA-1.4.4/HLK for kermit.misc@watsun); Fri, 5 May 1995 18:35:26 -0400
  5. Path: news.columbia.edu!panix!news.mathworks.com!gatech!swrinde!cs.utexas.edu!news.cs.utah.edu!cc.usu.edu!jrd
  6. From: jrd@cc.usu.edu (Joe Doupnik)
  7. Newsgroups: comp.protocols.kermit.misc
  8. Subject: Re: C-Kermit 5A(190) server mode problem
  9. Message-Id: <1995May5.114847.49869@cc.usu.edu>
  10. Date: 5 May 95 11:48:47 MDT
  11. References: <BAM.95Apr21171236@wcl-l.bham.ac.uk><B.A.MCCAULEY.95May4095228@wcl-l.bham.ac.uk><1995May4.173322.49759@cc.usu.edu> <B.A.MCCAULEY.95May5142149@wcl-l.bham.ac.uk>
  12. Organization: Utah State University
  13. Lines: 94
  14. Apparently-To: kermit.misc@watsun.cc.columbia.edu
  15.  
  16. In article <B.A.MCCAULEY.95May5142149@wcl-l.bham.ac.uk>, B.A.McCauley@bham.ac.uk writes:
  17. > In article <1995May4.173322.49759@cc.usu.edu> jrd@cc.usu.edu (Joe Doupnik) writes:
  18. >>In article <B.A.MCCAULEY.95May4095228@wcl-l.bham.ac.uk>, B.A.McCauley@bham.ac.uk writes:
  19. >>> In article <BAM.95Apr21171236@wcl-l.bham.ac.uk> B.A.McCauley@bham.ac.uk writes:
  20. >>>>When the terminal is MS-KERMIT 3.13.0 it works fine when the terminal
  21. >>>>is C-Kermit 5A(190) then the generic finish command is ignored (it's
  22. >>>>not even logged in the packet log). My software first sends a "N"
  23. >>>>packet (in case the server had send a "S" and I had missed it)
  24. >>>>followed by an "E" packet and finally sends an "I" packet, after which
  25. >>>>C-Kermit will accept the "GF" packet.
  26. >>    Hmmm. I don't think you want to do all that. First, a Kermit
  27. >>server sits around waiting for a client to start a session and make
  28. >>a request. It does NOT send S packets while waiting. It may send NAKs
  29. >>now and then to stimulate old clock-less Kermit clients. E packets are
  30. >>powerful things because they terminate a file transfer operation; don't
  31. >>use unless *really* needed.
  32. > 
  33. > I know all this and I agree that my client may not take the ideal
  34. > approach to attempting to recover the situation. This is not the issue
  35. > here, what I want to know is why C-Kermit is ignoring the GF packet in
  36. > the first place.
  37. > 
  38. >>    C Kermit did see the GF packet, ACK'd it, and logged both, as 
  39. >>your C Kermit packet log below clearly shows.
  40. > 
  41. > No it does not. Look again.
  42. > 
  43. >> Your E packet also shows.
  44. > 
  45. > And like I said this was sent to force a reset *after* the server failed
  46. > to respond to the GF packet. After this reset the next GF packet worked.
  47. > 
  48. >>    Now then, I've lost track of what was the real question.
  49. > 
  50. > What happened to the first GF packet? Not the one I sent after
  51. > resetting the server.
  52. > 
  53. >>>>Here is C-Kermit's packet.log (long data packet truncated).
  54. >>>>
  55. >>>>r-00-00-0 I~\ @-#Y2 J 5S#
  56. >>>>s-00-00-5 Y~* @-#Y2~^!5$0___CX
  57. >>>>r-00-01-% GD S
  58. >>>>s-00-01-5 S~* @-#Y2~^!5$0___AP
  59. >>>>r-00-01-0 Y~\ @-#N2 J 5S(
  60. >>>>s-01-01-*!Xls -l );
  61. >>>>r-01-00-$!Y">
  62. >>>>s-02-00-2"A."U1"#AMJ*!A@ -T
  63. >>>>r-02-00-$"Y"?
  64. >>>>s-03-04- #D08Rtotal 5349#M#Jdrwxr-xr-x   2 bam      staff        1024 Apr  5 12:54 backup.home#M#Jdrwxr-xr-x   2 bam      staf
  65. >>>>r-03-08-$#Y"@
  66. >>>>s-04-08-$$Z"B
  67. >>>>r-04-09-$$Y"A
  68. >>>>s-05-09-$%B"+
  69. >>>>r-05-09-$%Y"B
  70. > 
  71. > This is where I sent the GF packet. What happened to it? (BTW this is
  72. > reproducable, it's not a comms problem).
  73. > 
  74. >>>>r-00-19-# N3
  75. >>>>#-00-19-<echo:ignored>
  76. > 
  77. > What does this mean? This looks nothing like the last packet!
  78.  
  79.     Well, it means two things. First, the obvious one is a NAK
  80. was received and C Kermit declared it to be an echo of what it sent.
  81. This makes more sense as we look at the receive packet sequence numbers,
  82. the second pair of digits in the debug log. There is a gap of about
  83. ten of them above and that suggests C Kermit went back to being a quiet
  84. server and sent NAKs out now and then. The log picks up one echo and
  85. CK ignores it. Could your program be sending the NAK by any chance?
  86.     Taken together with your earlier comments on flow control 
  87. problems and extra padding etc (see the MS-DOS Kermit log for details)
  88. it does appear that the wire part of the circuit is not behaving well.
  89. Given that, CK may never have heard your first GF packet or if it did
  90. then maybe the packet was mangled to be a non-packet and hence not
  91. logged by CK. MSK logs everything, rational or not, as we have noticed.
  92.     Beyond this I think Frank da Cruz needs to plug in his crystal
  93. ball and beam it in this direction.
  94.     Joe D.
  95.  
  96. > OK my client is desparate now so it sends an E and I packet to reset
  97. > the server.
  98. > 
  99. >>>>r-00-29-E EToo many retries (expecting SXBFY)U
  100. >>>>r-00-30-0 I~\ @-#Y2 J 5S#
  101. >>>>s-00-30-5 Y~* @-#Y2~^!5$0___CX
  102. > 
  103. > OK the server is listening again so let's try the GF command.
  104. > 
  105. >>>>r-00-31-$ GF4
  106. >>>>s-00-31-# Y>
  107. > 
  108. > This time the GF packet worked.
  109.